IBIS Macromodel Task Group

Meeting date: 02 May 2023

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Aurora Systems:             * Dian Yang
Cadence Design Systems:     * Ambrish Varma
                              Jared James
Google:                       Hanfeng Wang
                              GaWon Kim
Intel:                        Michael Mirmak
                            * Kinger Cai
                              Chi-te Chen
                            * Liwei Zhao
Keysight Technologies:        Fangyi Rao
                              Majid Ahadi Dolatsara
                              Stephen Slater
                              Ming Yan
                              Rui Yang
Marvell:                      Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Graham Kus
Micron Technology:            Justin Butterfield
Missouri S&T:                 Chulsoon Hwang
                              Yifan Ding
                              Zhiping Yang
Rivos:                        Yansheng Wang
SAE ITC:                      Michael McNair
Siemens EDA (Mentor):       * Arpad Muranyi
                            * Randy Wolff
Teraspeed Labs:             * Bob Ross
Zuken USA:                  * Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

Randy: Post draft4 of the IBIS-AMI Ts4file port order BIRD proposal to the Open
       Forum as an official BIRD.
        - Done.  Randy had sent an email announcing BIRD224.

Arpad: Prepare a presentation and statement of the issue for the AMI_GetWave
       block size with continually adapting models topic.
       - Not Done.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the April 25th
meeting.  Ambrish moved to approve the minutes.  Lance seconded the motion.
There were no objections.

--------------
New Discussion:

How to handle the PSIJ Sensitivity BIRD draft and SPIM (BIRD223):
Arpad had added this item to the agenda to facilitate discussion about how to
handle these proposals.  Should they be part of IBIS, part of a new stand-alone
specification, or something else?

Walter shared a presentation on where these SPIM and PSIJ models would fit into
the overall scheme of IBIS.  He started with broad definitions of SI and PI.
- Signal Integrity
  - fundamental question revolves around the shape of the waveform and its
    transitions and threshold crossings at the latch.
  - Need to model:
    - Component internal timing
    - I/O Buffer Operation
    - Chip Interconnect
    - Package Interconnect
    - Board Interconnect
    - Connector Interconnect
Walter said that given information on the 6 "need to model" items, a simulator
can answer the fundamental SI question about the quality of the waveform at the
Rx latch.

Walter said that IBIS does not address Component Internal Timing.  He said it
had been discussed in the past, but the situation in the industry is that EDA
tools have their own proprietary timing models.  There has never been enough
desire to come up with a way to standardize it.  Sometimes customers may have
to put timing data into multiple models/libraries for the various tools, but
once that up front step is done things work.  Walter also said that IBIS doesn't
address board interconnect, though EMD provides similar functionality for
modules.  He observed that IBIS has a connector interconnect modeling
specification, though it was not widely adopted by the industry.

Walter said that his organization could have donated their component timing
model scheme to IBIS and asked IBIS to "publish" it.  If there's interest in
that, it could be done in the future.

Arpad noted that Walter's list of six items did not include power planes, which
could also affect the signal waveform transitions.  Walter said his interconnect
items included signal and power pins.  Arpad said this question would lead into
further questions about what is SI versus PI and their convergence.

Walter introduced Power Integrity.
- Power Integrity
  - We can solve for the time varying rail voltage waveform.
  - We can determine the spectral density of that waveform, e.g., the voltage
    at:
    - DC
    - 1kHz
    - 10kHz
    - ...
    - 100GHz
  - We need to model:                    Addressed By:
    - Component load requirements        SPIM?
    - I/O buffer load requirements       [Composite Current], SPIM?
    - VRM (voltage regulator module)
    - Chip Interconnect                   IBIS-ISS, SPIM?
    - Package Interconnect                IBIS-ISS, SPIM?
    - Board Interconnect                  EMD, EDA vendor?
    - Connector Interconnect

Walter said one question is where SPIM falls in these modeling categories.  A
second question is whether we should treat SPIM as we have done in the past for
component internal timing models.  That is, SPIM might be one particular way to
do it, but there might be multiple different modeling schemes used to provide
component load requirement information, for example.

Kinger responded that SPIM's primary focus is on platform PI design.  SPIM
models the chip and the package, and the model can be given to the platform
designer so they can quickly design and verify their platform.  Kinger said the
goal is to get beyond the existing paradigm of simply specifying a worst case
voltage noise amplitude.  Kinger said SPIM uses a normalized stimulus, but the
stimulus is weighted according to loads on the ports/blocks.  This provides
scalable load targets.  Kinger said that with SPIM you don't have to mix levels
(the "need to model" levels).  The computer (platform) designer doesn't care
about the on-die information.  SPIM lets the chip vendor provide a sufficient
but minimal amount of information to the platform designer.  SPIM, as proposed
in BIRD223, provides support for DC and AC analysis and modeling, but it can be
extended in the future.

Walter said he did not disagree with Kinger.  He said Kinger's proposal was
valuable, and he thought publishing SPIM 1.0 via IBIS was fine, but it might not
be ready to be part of the IBIS specification.  He said his concern was that
there are lots of models associated with solving SI/PI problems, and IBIS may
want to be a host platform for some of the (currently) proprietary models.
However, until there's a general desire for SPIM it should be a stand-alone
proposal and not necessarily part of the IBIS specification.

Kinger said that Intel had been delivering SPIM models to its customers since
2017.  He said that since 2015 they had worked with several of the leading EDA
companies in this space, together controlling about 90 percent of the market for
this platform level PI design software.  So, they had a holistic approach with
large OEM customers and EDA vendors in favor of this proposal.  Kinger said they
were offering to open source their SPIM methodology in much the same way they
had open sourced their I/O buffer information modeling to create IBIS 30 years
ago.

Arpad said that IBIS is a modeling language.  It allows the model maker to
describe buffers, packages, etc.  He said SPIM might be filling some gaps in
the information IBIS provides.  However, his fundamental question was whether
SPIM is straying into describing a methodology or simulation flow.  He said his
opinion was that IBIS should remain a modeling language/specification and not
define simulation methodologies and flows.  Dian said he thought the question
about how to handle SPIM was even more fundamental, should we treat PI modeling
as a part of IBIS?

Randy and Bob asked whether the tools and users interested in SPIM would care
whether SPIM is wrapped inside of IBIS itself?  For example, does the IBIS
[Component] add something important to SPIM that the tool would use, or could
SPIM be a stand-alone specification that refers to IBIS [Component]s.  Is the
direct linkage to an IBIS file needed for the EDA tools?  Kinger and Dian said
they thought it would be better to have SPIM in the IBIS specification.  It
would streamline the syntax and encourage greater adoption of SPIM.

Kinger noted that one compromise might be having a dedicated SPIM file and only
putting [Device SPIM Group] in the .ibs file.  He said that, as is done with
[Package Model], we might allow SPIM models directly in the .ibs file or in
separate .spim files referred to by .ibs files.

Arpad agreed that the current IBIS specification allows us to point to package
models in separate files.  However, he said we are now discussing whether the
specifications (SPIM and IBIS) should be in the same document or separated,
versus keeping the models themselves in separate files.

- Kinger: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

New ARs:

- None.

-------------
Next meeting: 09 May 2023 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
